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INTRODUCTION 

This  report  describes  the  remote  entry  system  developed  at 
the  Courant  Institute  of  Mathematical  Sciences  for  the  Control 
Data  6600  computer.   It  services  both  Interactive  time-sharing 
(CDC  INTERCOM)  and  batch  Job  processing  (NYU  XREMOTE) .   Central 
to  the  system  Is  a  16  bit  Honeywell  DDP  minicomputer  which  is 
interfaced  to  the  CDC  660O  (see  Figure  1).    The  DDP  can  be 
conceived  as  the  "front  end"  of  the  larger  computer  serving  the 
dual  functions  of  l/O  controller  and  temporary  storage.   l/O  in 
this  sense  Includes  both  physical  input/output  and  such  pre- 
processing as  error  checking,  control  character  processing,  code 
translations,  character  blocking,  etc.   By  moving  these  functions 
out  of  the  central  computer,  we  have  gained  considerable 
flexibility. 

There  are  many  different  terminal  systems  commercially 
available  and  almost  as  many  Incompatibilities  amongst  them.   Such 
incompatibilities  range  through  transmission  techniques  (automatic 
vs.  response  to  poll),  hardwired  control  character  generation  and 
checking,  data  codes,  etc.  etc.   It  is  obviously  worthwhile  not  to 
lock  into  a  specific  system  to  the  exclusion  of  others,  and  we 


We  currently  use  the  DDP-516  (see  Instruction  Manual  for  DDP-516, 
General  Purpose  Computer,  DOC.  No.  150071620-2;  Honeywell).   The 
Interface  was  developed  by  our  Engineering  Research  Laboratory  and 
is  fully  described  in  an  AEC  Research  and  Development  Report  "An 
Interface  Between  a  Control  Data  60OO  Series  Computer  and  a 
Honeywell  l6-Blt  Series  Computer";  R.  Blanchlnl;  NYO-l480-119,  New 
York  University,  October  1969- 


accomplished  this  goal  by  interfacing  directly  into  a  programmable 
computer  with  no  intervening  hardwired  tests  or  conversions. 
Since  the  entire  transmitted  bit  stream  enters  core  memory  and  is 

-X- 

available  for  software  analysis  ,  there  are  obviously  no  enforced 
restrictions  on  data  codes,  control  characters,  or  record  length. 
There  is  also  no  barrier  against  utilization  of  different  polling 
or  error  checking  techniques  and  we  can  support  a  variety  of 
remote  terminals. 

The  most  common  media  for  remote  data  transmission  are  half- 
duplex  common  carrier  telephone  lines.   Error  detection  across 
such  lines  requires  the  receiver  to  notify  the  transmitter  of 
proper  or  improper  reception  of  each  transmission  record.   This 
procedure  is  rather  time  consuming  (it  generally  requires  a  pause 
of  about  1/4  second  between  transmissions  in  different  directions 
—  a  total  of  1/2  second  per  acknowledgement)  and  it  is  most 
advantageous  to  Increase  the  size  of  the  transmission  record  by 
packing  together  several  data  records.   Our  production  system 
currently  supports  2  data  formats  (see  Appendix  A).   The  unit 
record  format  is  compatible  with  the  hardwired  Univac  DCT  2000, 
and  the  variable  length  packed  "binary"  format  is  used  by  remote 
computer  terminals  (currently  IBM-II30  and  DDP-516).   Typical 
transmission  speeds  are  about  60  cards  per  minute  for  the  DCT 
terminals  and  35O  cards  per  minute  for  computer  terminals.   An 


-X- 

Teletype  input  is  an  exception  to  this  rule.   Each  data 
character  is  framed  by  control  bits,  and  these  are  stripped  by 
a  hardwired  interface. 


additional  feature  of  the  binary  format  Is  deletion  of  trailing 
blanks,  and  actual  speeds  vary  from  200  to  600  cards  per  minute 
in  accordance  with  the  degree  of  truncation. 

Another  advantage  of  the  front  end  concept  is  its  flexi- 
bility to  change.   New  terminal  types  can  be  accommodated  by 
software  rather  than  hardware  modifications.   For  example,  we  are 
currently  developing  the  capability  to  support  the  CDC  200 
terminal.   This  hard-wired  device  differs  from  all  of  our  currently 
supported  terminals  along  a  very  broad  front  which  includes  data 
codes,  control  characters,  error  recovery,  and  polling  techniques. 
In  spite  of  all  this  our  flexibility  is  so  great  that  this  addi- 
tion poses  no  major  problem.   Also,  since  the  software  which  is 
to  be  modified  is  removed  from  the  central  computer,  it  has  been 
possible  to  build  a  very  safe  software  interface.   Failures  of 
DDP  software  do  not  bring  down  the  6600  operating  system,  and 
debugging  of  improvements  and  extensions  do  not  have  to  be 
traumatic . 

For  remote  batch  the  general  procedure  is  for  a  user  at  a 
remote  site  to  dial  one  of  our  automatic  answering  data  sets. 
Upon  establishing  a  connection  he  sets  the  data  set  controls  for 
data  transmission  and  may  Immediately  begin  to  read  and  transmit 
cards.   The  transmission  may  be  either  an  input  job  or  a  request 
for  output.   There  is  no  difference  between  a  remotely  entered 
job  and  a  locally  entered  job.   The  deck  structure  is  the  same 
for  both  and  the  66OO  operating  system  is  not  aware  of  the  source 
of  its  input.   Output  may  be  printed  locally  or  queued  for  trans- 
mission, in  accordance  with  control  cards  within  the  input  job. 
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Most  often  the  remote  users  store  their  programs  at  the 
central  computer,  and  input  jobs  consist  of  control  cards  to 
call  in  the  desired  program,  and  data.   Facilities  are  provided 
for  editing  and  updating.   Transmitted  output  is  usually  a  print 
file,  but  some  users  generate  punched  decks  from  which  incremental 
plots  are  produced.   Display  output  can  also  be  transmitted,  and 
this  will  indeed  be  the  case  for  the  CDC  200. 

Development  of  this  system  had  its  roots  in  the  implementa- 
tion of  the  SHARER  timesharing  system  in  1965-    At  that  time, 
the  manufacturer   offered  no  remote  entry  facilities  at  all,  and 
there  was  no  choice  but  to  do  it  ourselves.   CDC  has  since 
released  its  own  remote  entry  system  which  interfaces  a  hard- 
wired multiplexor  directly  onto  a  66OO  l/O  channel.   The  front 
end  processing  which  our  system  accomplishes  in  the  DDP  must  be 
handled  by  a  dedicated  resource  of  the  660O  system  —  a  peripheral 
processor.   The  price  paid  for  this  approach  must  include  the 
performance  degradation  of  the  overall  multiprogrammed  environ- 
ment due  to  loss  of  a  peripheral  processor. 


SHARER,  a  Timesharing  System  For  the  CDC  660O;  Harrison  and 
Schwartz;  Communications  of  the  ACM,  October  I967.   CDC  INTERCOM 
Is  a  direct  outgrowth  of  SHARER. 


1.  ENVIRONMENT 

The  physical  environment  with  which  we  are  concerned  is 
sketched  in  Figure  1.   The  CDC  660O  is  the  ultimate  source  (or 
recipient)  of  data  records  which  are  passed  through  the  DDP-660O 
Interface  by  synchronized  l/O  routines  in  the  two  machines.   The 
external  l/O  interfaces  include  the  necessary  modems  to  convert 
telephone  signals  to  digital  signals,  shift  registers  for  serial 
to  parallel  conversion,  and  interrupt  lines  to  signal  the  computer 
that  input  is  available  (or  output  is  required). 

They  include  1  byte  shift  registers  linked  to  (high  speed) 
201-A  Data  Sets  and  a  1  byte  multiplexor  linked  to  a  number  of 
(low  speed)  lOJ-A  Data  Sets  and  teletypewriters.    All  l/O  at  this 
end  of  the  system  is  on  a  byte  basis,  and  all  l/O  at  either  end 
of  the  DDP  is  on  demand  in  response  to  Interrupt. 

Before  describing  the  remote  entry  system,  a  brief  descrip- 
tion of  some  features  of  the  660O  hardware  configuration  and 
operating  system  Is  necessary. 

As  Indicated  in  Figure  2,  besides  the  CP  (central  processor) 
which  executes  all  user  programs,  there  are  ten  PP's  (peripheral 
processors)  each  of  which  is  essentially  an  autonomous  programmable 
computer  with  its  own  private  core  memory  (4K-12  bit).   These  PP's 
all  share  access  to  the  12  l/O  channels  and  to  the  central  (core) 


The  realized  transmission  rates  are  2000  bits  per  second  for  the 
201  and  10  characters  per  second  for  the  103-   We  have  the  capa- 
bility to  link  to  higher  speed  lines  as  well. 


memory  (I3IK-60  bit).   The  CP  has  access  only  to  central  memory, 
and  to  no  l/O  channel  or  PP  memory.   All  l/O  for  any  CP  program 
must  therefore  be  accomplished  by  a  PP  (Figure  5).   The  actual 
mechanism  for  the  CP  program  to  request  l/O  and  the  system  monitor 
procedures  to  assign  a  PP  and  maintain  l/O  channel  order  are  not 
particularly  relevant.   What  is  Important  is  that  l/O  is  to  (from) 
a  central  memory  buffer,  and  that  PP ' s  are  dynamically  assigned 
to  service  l/O  requests.   The  PP  accomplishes  its  task  by  over- 
laying part  of  its  memory  with  a  program  from  the  system  library 
(either  in  central  memory  or  on  mass  storage)  and  executing  the 
overlay.   It  is  worth  mentioning  that  the  660O  is  a  multiprogrammed 
machine  and  the  CP  is  shared  amongst  a  number  of  programs  in 
simultaneous  core  residence.   It  is  also  significant  that  the  6600 
has  no  hardware  interrupt  facility. 

The  remote  entry  system  to  be  described  here  is  used 
primarily  for  remote  (job)  batch  processing  and  timesharing.   In 
the  former,  a  660O  CP  program  (XREM0TE)  assembles  data  records 
onto  a  mass-storage  input  file,  and  transmits  data  records  from  a 
mass-storage  output  file.   In  the  latter,  user  CP  programs  are 
rolled  in  or  out  of  core  under  control  of  a  PP  "supervisor",  and 
terminal  l/O  is  transmitted  through  fixed  "system"  buffers.    What 
is  common  is  that  a  CP  orogram  finds  remotely  entered  data  in  a 
CM  (central  memory)  buffer,  and  deposits  data  destined  for  a 


This  is  the  current  procedure  under  CDC  INTERCOM.   The  procedure 
was  somewhat  different  under  NYU  SHARER. 


remote  site  Into  a  CM  buffer.   This  report  will  describe  how 
external  fata  Is  transmitted  through  the  system  until  It  reaches 
this  buffer,  and  how  Internal  data  Is  transmitted  from  such  a 
buffer.   It  will  not  describe  how  XREM0TE  processes  Its  data  files 
nor  how  INTERC0M  processes  its  records. 

It  is  worthwhile  mentioning  that  the  data  entry  system  is 
not  limited  to  the  above  mentioned  applications.   Any  Individual 
user  can  write  a  (non-INTERC0M)  program  to  communicate  with  a  tele- 
type without  automatic  swapping.   A  subsystem  supporting  graphic 
terminals  is  also  projected. 


XREM0TE  is  described  in  Appendix  B. 
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2.   THE  DDP  EXEC  SUPERVISOR,  AND  DATA  STRUCTURES 

The  next  section  of  this  report  will  describe  the  passage 
of  data  through  the  system  step  by  step.   This  section  defines 
the  software  environment  within  the  DDP  in  which  the  processes 
are  carred  out.   This  environment  is  entirely  our  own  design  and 
none  of  the  manufacturer's  software  was  utilized.   Implementation 
was  greatly  simplified  by  utilizing  2  other  in-house  products: 

1)  a  DAP  assembler  on  the  6600  which  produces  punched  decks 
which  are  in  turn  loaded  into  the  DDP  through, 

2)  DDT,  a  DDP  debug  program  which  includes  a  card  loader  in 
its  repertoire. 

The  system  is  composed  of  interrupt  routines,  subprograms, 
and  a  supervisor  (EXEC)  to  call  the  interrupt  routines  when 
requested,  schedule  execution  of  subprograms,  and  do  basic  house- 
keeping such  as  saving  and  restoring  registers  of  interrupted  sub- 
programs.  Interrupt  routines  are  characterized  by  their  demand 
for  relatively  fast  service.   An  external  device  must  generally 
dispose  rapidly  of  any  data  it  may  be  holding  in  order  to  be  able 
to  receive  additional  data  which  may  already  be  on  the  way. 
Alternatively,  after  transmitting  output  it  may  have  to  be  provided 
with  more  data  before  the  next  clock  cycle,  or  risk  invalidating 
an  entire  stream  of  bytes  (a  record).   An  exception  to  this  rule 
is  output  to  a  teletype,  where  slow  service  will  not  affect  the 


system  significantly.    For  uniformity,  however,  we  will  consider 
all  interrupt  routines  to  demand  fast  service.   In  our  implementa- 
tion this  constraint  was  satisfied  by  inhibiting  all  interrupts 
during  any  interrupt  routine  (precluding  later  interrupts  from 
interfering  with  completion  of  the  current  task)  and  severely 
limiting  the  amount  of  processing  to  be  done  during  an  Interrupt 
routine  (guaranteeing  that  later  Interrupts  be  serviced  within  a 
"reasonable"  delay). 

This  latter  attribute  of  the  interrupt  routines  motivates 
the  overall  l/O  design  illustrated  in  Figure  4.   Each  input  byte 
is  Indlscrlmlnantly  placed  into  a  simple  buffer  by  the  interrupt 
routine,  only  later  to  be  examined  by  a  subprogram  which  will 
determine  what  action  (control  or  data  transmission)  to  take,  and 
if  necessary  move  it  to  a  "Device  Buffer"  where  records  are 
assembled.   On  output,  the  next  control  or  data  byte  to  be  trans- 
mitted must  be  placed  in  the  proper  buffer  slot  by  a  subprogram, 
and  the  interrupt  routine  will  merely  transmit  one  byte  from  this 
location. 

EINT  and  ESCN 

EXEC  is  composed  of  2  basic  routines  -  EINT  and  ESCN.   (Flow 
charts  are  shown  in  Figure  5- )   Control  is  transferred  to  EINT  by 
a  hardware  Interrupt.   Each  subprogram  known  to  EXEC  has  associated 
with  it  a  set  of  locations  for  storing  registers  on  Interrupt,  and 


At  one  time  our  system  did  discriminate  between  these  2  types  of 
interrupts,  and  permitted  some  interrupt  routines  to  be  Interrupted 
by  others  (priority  interrupts).   Upon  Implementation  of  EXEC,  it 
was  felt  that  the  distinction  was  no  longer  required. 


one  "state  word"  In  which  is  recorded  whether  the  subprogram  is 
in  "idle",  "run",  or  "interrupt"  state.   In  addition  there  is  one 
pointer  word  ENUM  which  either  points  to  the  running  program 
(when  non-zero),  or  indicates  that  ESCN  is  running  (when  zero). 
Hence  on  entry  to  EINT,  if  ENUM  is  non-zero,  all  registers  are  to 
be  stored  in  the  running  program's  tables.   Then  the  external 
devices  are  tested  to  determine  which  generated  the  interrupt. 
Priority  of  interrupt  service  is  determined  solely  by  this  sequen- 
tial testing,  and  may  be  modified  by  reassembly.   As  soon  as  an 
interrupting  device  is  discovered,  a  Jump  to  the  proper  routine  is 
executed. 

On  return  from  the  interrupt  routine,  ENUM  is  set  to  zero, 
interrupt  is  enabled,  and  the  ESCN  loop  entered.   The  state  table 
is  scanned  until  a  subprogram  is  found  with  state  equal  to  "run" 
or  "interrupt",  upon  which  this  subprogram  is  executed  (if  it  is 
in  interrupt  state,  the  registers  are  first  loaded  and  a  jump  to 
the  interrupted  location  executed).   If  the  subprogram  runs  to 
completion,  it  is  assumed  that  all  its  tasks  are  completed  and  its 
state  set  to  idle.   ESCN  then  continues  the  scan  of  the  state 
table  at  the  next  entry.   If  the  subprogram  is  interrupted,  regis- 
ters are  saved  by  EINT  as  above,  and  when  ESCN  is  again  entered, 
the  scan  of  the  state  table  begins  at  the  top.   Priorities  of  sub- 
programs are  thus  determined  solely  by  the  position  of  their 
associated  state  word  within  the  table.   Since  all  subprograms  are 
set  to  idle  upon  completion,  any  interrupt  which  requires  a 
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subprogram  to  service  its  byte  buffer  (see  Figure  4)  must  set  the 
state  of  that  subprogram  to  "run"  if  it  is  currently  at  "idle". 
As  already  mentioned,  the  66OO  has  no  hardware  interrupt 
facility,  and  because  of  this  lack  all  l/O  between  the  machines 
is  initiated  by  the  660O.     The  PP  assigned  to  service  a  CP  l/O 
request  first  issues  a  channel  function  to  interrupt  the  DDP.   This 
interrupt,  however,  does  not  share  the  above  mentioned  defining 
characteristics  of  interrupt  routines.   It  is  not  unreasonable  for 
the  PP  to  be  forced  to  wait  for  service  from  the  DDP,  and  on  the 
other  hand  since  data  blocks  rather  than  bytes  are  to  be  trans- 
ferred, it  is  unreasonable  to  lock  out  other  devices  during  the 
(relatively)  long  DDP-PP  conversation.   Since  this  conversation 
is  more  similar  in  character  to  a  subprogram  than  to  an  interrupt 
routine,  it  has  been  made  into  a  subprogram.   When  the  660O  PP 
interrupts  the  DDP,  the  only  functions  the  DDP  interrupt  routine 
executes  are  1)  reset  the  interrupt  flip-flop,  and  2)  set  the  state 
of  the  conversation  subprogram  to  "run". 


* 

There  is  provision  for  a  subprogram  to  make  a  non-standard  exit 

leaving  itself  in  "interrupt"  state  and  causing  ESCN  to  continue 

scanning  at  the  next  entry. 

An  alternative  to  this  procedure  (used  by  CDC  themselves  in 
their  own  remote  entry  system)  is  to  dedicate  a  PP  to  remote  l/O. 
This  PP  continuously  polls  for  data,  and  whenever  available  the 
data  is  passed  on.   Such  an  approach  degrades  overall  660O  per- 
formance (the  system  loses  a  prime  resource)  and  is  only  used  be- 
cause their  system  lacks  a  "front-end"  to  serve  the  functions  of 
our  DDP. 
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3-   DATA  PATHS  THROUGH  THE  SYSTEM 

This  section  of  the  report  Is  divided  into  2  subsections: 
A)  External  Device  to  Device  Buffer,  (record  buffer  of  Figure  4); 
and  B)  Device  Buffer  to  6600.   Since  the  Device  Buffers  serve  as 
a  terminus  in  both  sections,  we  will  first  briefly  describe  their 
rather  elementary  structure.   As  illustrated  in  Figure  6,    a 
contiguous  block  of  storage  is  sequentially  partitioned  into  64 
linear  buffers  by  an  address  table  of  pointers  to  the  beginning 
of  each  buffer.   Each  buffer  extends  until  the  next  buffer  and  is 
assigned  by  assembly  parameter  to  at  most  one  external  device, 
(in  order  to  facilitate  projected  implementation  of  Interleaving 
remote  batch  input  with  output,  the  remote  batch  terminals  have 
been  assigned  2  buffers  each. )   Associated  with  the  buffers  is  a 
table  of  status  words  (one  word  per  buffer)  which  maintain  informa- 
tion on  the  current  status  of  the  buffer. 

All  data  stored  in  these  buffers  Is  in  6600  internal  format. 
No  conversions  are  performed  between  this  point  and  6600  central 
memory  and  the  peripheral  processor  programs  that  execute  this 
final  portion  of  the  journey  are  completely  oblivious  of  the  con- 
tents of  their  baggage.   To  further  facilitate  this  last  process, 
only  12  bits  of  the  DDP  l6  bit  word  are  used  to  store  data  —  for 
12  bits  is  both  the  capacity  of  the  6600  l/O  channel  and  the  word 
size  of  the  PP  core  memory.   The  DDP  subprograms  which  shuffle 


Not  all  64  buffers  are  in  current  use, 
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data  between  byte  buffers  and  Device  Buffers  convert  external 
8  bit  code  to  the  660O  6  bit  code  and  pack  the  data  2  characters 
to  a  word,  Into  the  proper  slot.   On  output,  the  Inverse  function 
is  performed. 

A  brief  description  of  the  status  table  of  Figure  6  will 
complete  this  introduction.   Each  word  is  composed  of  3  binary 
flags  and  a  pointer.   The  flags  indicate:   1)  Buffer  contains  a 
complete  record  ready  to  input  to  the  660O;  2)  Buffer  contains 
output  from  the  660O;  3)  Buffer  is  reserved  (generally  used  to 
bar  undesired  entry  of  data  from  660O).   The  pointer  is  used  by 
the  above  mentioned  subprograms  to  pack  or  unpack  data  into  or 
from  the  next  available  buffer  slot.   Upon  completion  of  a  record 
for  the  6600  the  input  flag  is  set  and  the  pointer  is  left  intact, 
indicating  the  size  of  the  record  to  be  transmitted.   On  receiving 
output  from  the  660O,  the  output  flag  is  set  and  the  pointer 
initialized  at  0.   There  is  no  direct  indication  of  the  size  of 
the  record,  but  the  last  word  of  the  record  is  flagged  (4  bits  of 
each  data  word  are  available  for  flags). 

A)  Data  Paths  from  External  Device  to  Device  Buffer 

As  shown  in  Figure  4,  the  system  supports  2  basic  l/O  inter- 
face types,  and  processing  differs  accordingly.   Although  the  basic 
unit  of  data  processed  by  a  single  l/O  instruction  is  in  both  cases 
an  8  bit  byte,  for  the  higher  speed  devices  this  byte  is  physically 
and  logically  embedded  in  a  larger  bit  stream.   Bit  serial  trans- 
mission of  data  demands  that  the  receiver  synchronize  itself  to 
the  start  of  the  transmitted  data  and  clock  the  incoming  bits 
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according  to  the  agreed  bit  rate.   Clocking  is  always  a  hardware 
function.   The  receiving  clock  for  low  speed  transmission  is 
contained  within  the  receiving  data  set,  but  the  high  speed  trans- 
mission sends  a  clock  signal  along  with  the  data.   This  facilitates 
clocking   long  bit  streams  without  losing  synchronization,  and 
whereas  the  hardware  for  the  low  speed  transmission  synchronizes 
each  data  byte  separately  (extra  bits  are  appended  and  then 
stripped),  synchronization  of  the  higher  speed  transmission  is 
performed  but  once  for  each  record. 

Synchronization  of  high  speed  transmission  is,  in  our  system, 
performed  by  software.   All  messages  transmitted  via  the  201  data 
sets  must  be  preceded  by  a  specified  3  bit  sequence  —  termed  a  SYNC 
character  —  and  this  character  must  be  recognized  before  any  other 
input  is  accepted.   Since  the  receiving  hardware  is  unaware  of 
synchronization,  it  may  very  well  begin  clocking  data  bits 
(probably  all  zero)  before  any  actual  data  is  transmitted,  offering 
each  set  of  3  clocked  bits  to  the  DDP  as  input.   This  will  very 
likely  cause  the  true  data  to  be  offset,  each  true  data  byte  being 
spread  over  2  input  bytes  (see  Figure  7).   The  SYNC  recognition 
routine  examines  all  combinations  of  the  2  most  recent  inputs,  and 
when  it  finds  a  SYNC  records  the  offset  in  SHFI  to  permit  proper 
registration  of  succeeding  characters.   The  procedure  we  follow 
(see  Figure  Y),    is  that  the  Interrupt  routine  Inputs  a  byte  to 
array  NEW  setting  the  indicated  flag.   Later  the  associated  sub- 
program extracts  a  character  from  NEW  and  OLD  using  the  offset 
from  SHFI,  moves  NEW  to  OLD  and  turns  off  the  flag  to  indicate  that 
NEW  is  now  empty. 
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Input  from  the  low-speed  devices  is  straightforward.   The 
multiplexor  registers  the  character  and  attaches  an  Identifier 
(tty  number)  to  each  character.   (For  Input  from  the  higher  speed 
lines.  Identifiers  are  not  needed  —  each  line  Is  a  separate 
addressable  external  device.)   The  Interrupt  routine  merely  stores 
any  Inputs  Into  the  next  slot  of  a  circular  buffer  where  the 
associated  subprogram  will  ultimately  find  It. 

There  Is  one  more  difference  between  the  two  l/O  Interface 
types.   The  higher  speed  devices  support  half-duplex  lines,  which 
means  that  although  data  can  be  transmitted  In  either  direction, 
the  direction  at  any  one  Instant  Is  determined  by  the  status  of 
the  supporting  equipment.   If,  for  example  the  data  set  Is  set 
(by  programmed  Instruction  from  the  computer)  for  output  It  will 
not  even  be  aware  of  data  transmitted  to  It  on  the  line,  and 
conversely  If  set  for  Input  It  will  be  unable  to  accept  any  data 
output  from  the  computer.   The  multiplexor,  however,  supports  full- 
duplex  lines,  which  means  that  it  is  always  possible  to  either 
input  or  output  a  byte  (provided  of  course  that  transmission  of 
any  prior  byte  has  been  completed). 

The  first  step  in  processing  a  teletype/multiplexor  input 
byte  Is  to  determine  if  the  Device  Buffer  can  accept  it,  and  there 
are  two  conditions  for  automatic  rejection  —  output  flag  or  input 
flag  set  (contains  output  or  a  complete  line  for  the  660O).   A 
third  condition  —  buffer  full  —  allows  control  characters  to  be 
processed,  but  no  data  can  be  accepted.   There  are  basically  three 
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controls,  and  the  actions  to  be  performed  are  straightforward: 

1)  Line  completed  -set  input  flag 

2)  Erase  partial  line      -set  pointer  to  zero 

3)  Backspace  -decrement  pointer 

Errors  are  generally  ignored,  the  only  error  reported  back  to  the 
user  being  the  "overwrite"  condition  —  a  byte  of  all  ones.   This 
condition  generally  results  from  the  multiplexor  receiving  input 
on  a  line  before  a  prior  input  has  been  accepted  by  the  DDP,  but 
it  may  also  be  generated  by  depressing  the  Rubout  key  on  the  tele- 
typewriter.  The  action  taken  is  to  place  a  blank  and  a  question 
mark  in  the  Device  Buffer,  and  set  the  output  flag  in  the  status 
word.   This  will  cause  the  question  mark  to  be  printed  at  the 
teletype  —  signalling  the  typist  that  his  current  line  has  been 
discarded . 

If  none  of  the  grounds  for  rejection  hold,  and  the  byte  is 
a  valid  character,  it  is  translated  into  6  bit  6600  code  via  an 
indexed  translation  table,  stored  in  the  Device  Buffer,  and  the 
buffer  pointer  is  incremented. 

The  teletype/multiplexor  output  subprogram  can  be  described 
very  briefly.   A  linear  scan  is  performed  on  those  Device  Buffer 
status  words  belonging  to  teletypes,  and  a  character  is  extracted 
from  any  buffer  whose  output  flag  is  set.   The  character  is  trans- 
lated into  8  bit  ASCII,  appended  with  an  identifier  (tty  number) 


In  a  different  class  of  controls  is  the  "break",  which  is  a 
command  to  the  6600  timesharing  system  to  enter  command  mode.   This 
control  is  always  recognized.   The  request  is  forwarded  to  the  6600 
through  Device  Buffer  zero,  which  is  designated  a  system  buffer  and 
not  linked  to  any  external  device. 
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and  placed  in  the  output  byte  buffer  to  be  picked  up  by  the 
associated  Interrupt  routine.   (if  the  character  Is  In  the  first 
buffer  position  It  Is  translated  Into  a  carriage  control  byte.) 
The  status  word  pointer  Is  Incremented  unless  the  character  was 
flagged  as  being  the  last.  In  which  case  the  status  word  Is 
cleared  and  the  buffer  Is  ready  for  Input  from  the  teletype  or 
output  from  the  660O. 

The  teletype  Input/output  programs  just  described  are 
characterized  by  their  highly  local  attitude.   Each  Input  charac- 
ter Is  processed  with  no  regard  to  what  preceded  It  and  no  concern 
for  what  may  follow.   The  only  matter  of  any  concern  Is  the  status 
of  the  device  buffer,  and  this  consideration  Is  dealt  with 
Immediately  —  the  character  Is  either  accepted  or  Ignored.   For 
the  higher  speed  l/O,  however.  Input  must  be  analyzed  In  a  more 
global  context.   Each  Input  record  contains  specific  control 
characters   which  determine  how  subsequent  control  or  data  Is  to 
be  Interpreted.   In  order  to  properly  process  any  byte,  the  pro- 
gram must  have  knowledge  of  which  Inputs  are  currently  valid,  and 
what  action  they  require  In  the  light  of  previously  processed 
Inputs. 

The  approach  we  have  used  to  handle  this  situation  Is  shown 
schematically  In  Figure  8.   TPV  Is  a  transfer  vector  each  compo- 
nent of  which  Is  the  address  of  the  particular  subroutine  which 
will  process  the  next  Input  from  the  associated  data  set.   (if 
the  output  flag  is  set,  the  address  is  that  of  a  subroutine  to 
provide  output. )   All  components  of  the  vector  are  Initialized 
with  the  address  of  the  SYNC  search  routine.   When  a  SYNC  is 
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discovered  for  any  data  set,  the  corresponding  component  is 
changed  to  the  address  (in  our  schematic  diagram)  of  subroutine  1, 
and  upon  input  of  the  first  character  is  again  changed  to  that  of 
subroutine  2A ,  2B,  or  ERROR  in  accordance  with  the  value  of  the 
character. 

The  various  control  characters  and  their  required  responses 
will  not  be  covered  herein  —  that  discussion  requires  fairly 
extensive  detail  and  is  reserved  for  an  appendix.   Suffice  it  to 
say  that  the  control  characters  may  direct  the  output  of  a  new 
record,  or  may  specify  the  format  of  input  data  embedded  within 
the  current  record.   As  described  in  Appendix  A,  2  very  distinct 
input  formats  are  supported.   The  first  is  standard  8  bit  ASCII, 
and  for  this  case  the  characters  are  translated  and  packed  into  the 
Device  Buffer  precisely  as  for  teletype  input  above.   The  second 
is  a  "pre-digested"  6  bit  code  for  which  every  three  8  bit  input 
bytes  contain  four  6  bit  characters.   In  this  case  the  characters 
are  packed  directly  into  the  Device  Buffer  without  translation. 
In  either  case,  whenever  an  entire  record  is  received  error  free, 
the  status  word  input  flag  is  set  —  indicating  input  for  the  6600  — 
and  a  proper  response  (a  sequence  of  control  characters)  sent  back 
through  the  data-set  informing  the  terminal  that  it  may  transmit  a 
new  record  if  it  so  desires. 

Output  is  accomplished  according  to  the  same  pattern.   The 
transfer  vector  leads  through  a  sequence  of  control  characters 
which  are  placed  one  at  a  time  into  the  output  byte  buffer  as  the 
interrupt  routine  empties  it.   When  data  is  to  be  sent,  a  character 
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is  taken  from  the  next  slot  In  the  Device  Buffer,  translated  into 
ASCII  and  placed  in  the  byte  buffer. 

Whenever  an  output  record  has  been  completed  —  whether  it 
was  data  or  a  response  to  the  terminal  —  the  transfer  vector  is 
set  to  search  for  SYNC,  and  the  next  move  is  up  to  the  terminal. 

B)  Device  Buffer  to  66OO 

Before  discussing  data  transfers  between  the  two  computers, 
we  must  first  describe  a  few  hardware  features  of  the  interface. 
As  depicted  in  Figure  9,    the  interface  appears  to  either  computer 
as  two  separate  external  devices  —  both  accessible  through  standard 
programmed  l/O  instructions.   One  device,  the  status  register,  is 
always  in  a  ready  state  —  the  12  bits  constitute  one  word  and  may 
be  read  into  either  machine  at  any  time.   Also,  the  indicated  bits 
may  always  be  written  by  the  respective  machines.   Some  of  the  bits 
have  hardware  significance,  while  some  merely  record  software 
information.   The  functions  are  indicated  in  the  table  appended  to 
Figure  9- 

Data  is  transferred  when  one  computer  outputs  12  bits  into 
the  holding  register  from  whence  its  partner  inputs.   The  state  of 
this  half -duplex  register  (it  must  be  conditioned  for  the  desired 
direction  of  data  flow)  is  subject  to  PP  control,  and  is  not  always 
ready.   The  PP  establishes  the  direction  of  data  flow  by  setting 
the  direction  bit  of  the  status  register  (1  for  input  to  the  660O, 
0  for  output),  and  "readies"  the  holding  register  by  executing  an 
"activate  channel"  instruction.   Neither  machine  can  execute  con- 
secutive outputs  until  its  partner  has  emptied  the  register  by 
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executing  an  input  instruction.   The  PP  instruction  set  contains 
tests  for  the  various  states  of  the  channel  and  register. 

The  other  hardware  oriented  bits  of  the  status  register  are 
the  interrupt  and  the  Interrupt  mask  bits.   The  latter  affords  the 
DDP  the  means  to  selectively  inhibit  program  Interrupts  from  the 
interface,  facilitating  operation  of  the  DDP  as  a  stand  alone 
device.   In  our  system  this  bit  is  always  set  at  1  —  interrupt 
enabled.   The  interrupt  bit  can  be  set  to  1  only  by  the  PP,  and 
reset  to  0  only  by  the  DDP.   The  former  condition  generates  an 
interrupt  to  the  DDP  program,  causing  a  transfer  of  control  to  the 
EXEC  routine  EINT  and  blocking  any  further  Interrupts  until  the 
program  executes  an  ENABLE  instruction.   Before  doing  so,  it  is 
necessary  to  reset  the  Interrupt  bit,  "satisfying"  the  Interrupt 
and  avoiding  re-entry  to  EINT. 

Whenever  a  PP  program  generates  an  Interrupt  on  the  DDP 
program  by  setting  the  interrupt  bit.  It  Includes  in  the  low  bit 
positions  of  the  status  mask  an  identifying  bit  pattern.   The  DDP 
reads  the  status  register  and  determines  which  of  3  procedures  is 
being  requested: 

1)  Input  to  the  6600  —  set  input  subprogram  to  run  state; 

2)  Output  from  the  6600  —  set  output  subprogram  to  run  state; 

3)  Error  recovery  _  set  both  subprograms  to  stop  state. 

Bit  6  —  the  ping  pong  bit  —  has  a  special  significance.   In 
the  conversational  procedures  to  be  described  blow,  the  status 
register  is  used  as  a  means  for  one  machine  to  post  information 
—  I  have  (or  have  not)  another  date  record  —  and  for  its  partner 
to  reply  —  send  it  (or  don't  send  it).   In  this  usage  it  Is 
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necessary  for  either  machine  to  be  able  to  determine  whether  Its 
partner  has  written  to  the  status  register  after  It  last  posted 
Its  own  Information,  or  whether  the  partner  has  not  yet  had  a 
chance  to  reply-   The  convention  Is  for  the  PP  to  set  and  for  the 
DDP  to  reset  the  ping  pong  bit.  Indicating  who  last  wrote  to  the 
status  register.   Both  the  DDP  and  PP  programs  are  equipped  with 
"wait  loops"  where  they  idle  while  awaiting  a  reply  and  the  PP 
wait  loop  has  a  timeout  exit  to  an  error  recovery  routine. 

The  error  recovery  procedure,  already  twice  alluded  to,  is 
both  simple  and  effective.   The  PP  merely  writes  to  the  status 
register  setting  the  interrupt  bit  and  the  error  recovery  identifi- 
cation pattern  in  the  low  order  bits,  and  then  exits.   The  DDP, 
upon  responding  to  the  interrupt,  stops  any  subprogram  which  may 
be  attempting  to  communicate  with  the  now  silent  PP,  and  continues 
with  other  processing.   This  rather  elementary  approach  is  made 
quite  effective  by  a  consideration  in  the  data  transfer  procedure. 
No  buffer  status  is  changed  in  any  way  until  an  entire  record  Is 
transferred  to  completion.   If  an  error  recovery  should  be  necessary 
in  the  midst  of  a  transfer,  the  entire  record  would  still  be  found 
in  its  original  place  and  original  state,  and  no  part  of  it  would 
be  remembered  in  the  companion  machine.   A  subsequent  l/O  attempt 
will  ultimately  cause  transfer  of  the  record. 


Bits  9  and  10  are  used  by  the  DDP  to  record  whether  or  not  there 
are  any  complete  input  records  from  the  low-speed  or  high  speed 
devices  respectively.   They  may  be  checked  by  a  660O  program  prior 
to  calling  for  input,  and  their  chief  use  is  to  minimize  660O 
processor  usage  while  awaiting  inputs.   The  data  transfer  routines 
make  no  use  of  them. 
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The  6600  peripheral  processor  can  accomplish  l/O  either  In 
a  block  mode  (directly  to  memory)  or  single  word  mode  (through  the 
A  register).   Although  the  former  Is  much  faster,  In  our  situation 
where  we  cope  with  2  asynchronous  computers.  It  Is  not  acceptable. 
A  primary  design  objective  has  been  to  Insulate  the  660O  as  much 
as  possible  from  hardware  or  software  failures  of  the  DDP  system. 
One  of  the  cardinal  rules  Is  that  the  PP  not  execute  any  Instruc- 
tion which  depends  on  the  DDP  for  successful  completion.   If  a 
block  transfer  were  Initiated  and  the  DDP  were  to  fall  to  cooperate 
at  any  time  before  the  last  word  were  successfully  transferred, 
the  PP  would  be  unable  to  recover.   In  single  word  mode,  however, 
the  PP  can  check  the  status  of  the  Interface  before  Inputting  or 
outputtlng  each  word.   If  the  DDP  has  not  responded  by  providing  a 
new  data  word  (or  accepting  the  last  one  offered),  a  timeout  loop 
Is  entered  In  which  the  status  Is  periodically  retested.   If  the 
status  is  still  unacceptable  after  a  more  than  reasonable  time 
delay,  the  error  exit  is  performed. 

As  mentioned  at  the  very  beginning  of  this  report,  in  the 
SCOPE  system  environment  PP  programs  are  transient.   A  central 
processor  program  which  wishes  to  do  l/O  communicates  this  desire 
to  the  system  monitor  which  assigns  a  PP  to  the  requesting  program. 
The  PP  overlays  itself  with  a  general  purpose  l/O  service  routine 
which  amongst  other  tasks  determines  to  (from)  which  external 
device  l/O  is  to  be  performed,  and  in  turn  calls  in  another  overlay 
—  an  equipment  driver  —  to  actually  execute  the  data  transfers. 
There  are  two  such  drivers  to  service  the  DDP  —  one  for  input  and 
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one  for  output.    Each  of  these  drivers  initiates  a  conversation 
with  the  DDP  by  generating  an  Interrupt  via  the  status  register 
and  (via   low-bit  settings)  requesting  the  DDP  to  start  an  input 
to  6600  subprogram  or  an  output  from  660O  subprogram. 

On  Input  to  the  660O,  the  driver  extracts  from  central  memory 
an  indication  as  to  which  device  buffer(s)  the  central  program 
wishes  to  input,  and  then  outputs  2  words  (LO  and  HI)  delimiting 
the  range  which  the  DDP  will  scan  for  input.   For  each  input  record 
found  within  this  range,  the  DDP  will  output  2  words  —  device 
buffer  number  and  size  of  record  —  and  the  PP  will  indicate  either 
a  desire  for  the  record  or  rejection  of  it.   On  output  from  the 
6600,  the  driver  must  first  read  a  data  record  from  the  central 
memory  buffer  Into  its  own  memory.   The  destination  (device  buffer) 
is  encoded  into  the  beginning  of  the  record,  and  the  PP  will  now 
output  2  words  —  device  buffer  number  and  record  size  —  allowing 
the  DDP  to  accept  or  reject  the  record.   Transfers  from  DDP  to  PP 
or  from  PP  to  DDP  are  thus  basically  symmetric,  with  the  sender 
scanning  for  data  records  to  be  transferred  and  informing  the 
receiver  either  (via  the  status  register)  that  there  are  no  more 
records  or  (via  a  2  word  output)  giving  the  vital  information  about 
the  records.   It  is  then  up  to  the  receiver  either  to  indicate 


For  the  INTERCOM  timesharing  system,  yet  a  third  PP  program  has 
been  implemented.   This  program  is  recalled  periodically  by  the 
system  monitor,  and  attempts  l/O  in  accordance  with  the  status  of 
system  buffers.   The  program  essentially  incorporates  both  drivers 
as  subroutines,  and  plays  the  role  of  input  or  output  exactly  as 
the  drivers  themselves. 
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rejection  (via  the  status  register)  or  to  accept  the  record.   The 
entire  procedure  is  shown  schematically  in  Figure  10.   When  the 
PP  plays  the  receiver  role,  part  of  the  "housekeeping"  in  the 
final  block  is  the  writing  of  the  record  from  PP  memory  into  cen- 
tral memory. 

This  section  will  be  completed  with  description  of  the  basis 
for  the  accept-re ject  decision.   The  PP  input  driver  as  already 
mentioned,  has  been  informed  by  the  central  program  as  to  which 
device  buffers  are  desired  —  and  any  others  preferred  evidently 
have  a  different  destination  and  are  rejected.   Secondly,  if  the 
central  memory  buffer  has  insufficient  room  for  the  preferred 
record,  a  rejection  is  also  in  order  —  hopefully  the  central  pro- 
gram will  remove  some  of  the  buffer  contents  and  again  request 
input.   The  DDP  on  the  other  hand,  has  neither  of  these  concerns 
to  deal  with,  and  will  accept  a  preferred  record  if  the  indicated 
device  buffer  is  empty  and  not  reserved.   If  the  record  is  too 
large  for  the  buffer  (through  someone's  error),  the  record  is 
accepted  but  the  excess  words  are  thrown  away  —  for  there  never 
will  be  room  for  them. 
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APPENDIX  A  -  BINRT,  REMOTE  PREPROCESSOR 

BINRT  is  a  DDP  subprogram  under  control  of  the  EXEC  super- 
visor whose  function  is  to  process  input  from  and  prepare  output 
for  the  data  set  interrupt  routines.   It  is  assumed  that  the 
reader  is  already  familiar  with  the  hardware-software  environment 
of  BINRT,  and  also  with  the  transfer  vector  (TPV)  technique 
described  in  the  text  (  Section  J>A)    and  illustrated  in  Figure  8. 
What  is  to  be  described  herein  is  essentially  the  details  of  this 
process,  and  we  will  first  establish  the  rules  of  conversation 
under  which  we  operate.   It  should  be  recalled  that  the  660O  pro- 
gram XREM0TE  communicates  with  BINRT  via  one  input  and  one  output 
device  buffer  per  data  set. 

I .  General  Conversation  Rules 

There  are  two  types  of  records  transmitted  —  data  and 
reply/request  —  and  the  record  defines  itself  in  its  first  byte. 
There  are  but  four  valid  characters  in  this  position: 

1.  SOH  (start  of  header)  —  Data  record  (additional  control 
characters  follow). 

2.  ACK  (acknowledgement)  -  Received  a  record  error-free. 

3.  NAK  (non-acknowledgement)  —  Received  a  record  with  error(s) 
or  received  no  record  and  one  is  desired. 

4.  ENQ  (inquiry)  —  send  a  record. 

The  ENQ  is  a  start-up  signal  for  transmission  and  is  included 
because  some  remote  terminals  generate  it  upon  manual  depression 
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of  a  console  button.   Actually  it  is  treated  precisely  as  a  NAK, 
and  we  will  henceforth  make  no  explicit  reference  to  it. 

The  general  communication  rule  is  that  for  each  received 
record  a  record  is  to  be  transmitted  —  data  in  return  for  ACK/NAK 
and  ACK/NAK  In  return  for  data.   In  our  implementation  we  have 
simplified  the  conversation  process  by  assigning  the  remote  station 
an  active  role  and  retaining  a  purely  passive  role  for  ourselves. 
This  passivity  encompasses  two  characteristics:   1)  Initiate  no 
action;  and  2)  react  to  the  active  partner's  action  only  on  a 
strictly  local  basis.   By  local  it  is  meant  that  after  reacting 
to  a  data  or  ACK/NAK  record  we  return  to  an  equilibrium  state 
where  there  is  no  memory  of  what  has  previously  transpired  —  the 
data  set  is  set  for  input  and  TPV  is  set  to  search  for  SYNC.   The 
required  local  reactions  to  the  various  received  records  are: 

1)  Data  record  —  error  free       -ACK 

2)  Data  record  —  with  error       -NAK  or  nothing 

3)  NAK  -Transmit  a  data  record 

from  the  proper  output 
buffer 

4)  ACK  -Request  a  record  from 

the  6600.*  When  it  is 
deposited  in  the  output 
buffer,  transmit  it. 

The  remote  station  (the  active  partner)  must  have  the  capa- 
bility to  react  in  essentially  the  same  manner  as  we  do,  but  in 
addition  it  must  be  able  to  initiate  action  and  maintain  a  .slightly 


The  6600  must  have  been  informed  where  the  record  is.   This  sub- 
ject is  described  in  "Appendix  B  —  XREM0TE".   The  mechanics  of 
requesting  the  record  will  be  described  below. 
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more  global  perspective  on  proceedings.   Initiation  is  straight- 
forward —  to  transmit  send  the  first  record,  and  to  receive  send 
an  ACK  or  a  NAK.   After  transmission,  however,  it  is  unacceptable 
to  retreat  to  an  equilibrium  state  as  above,  for  there  is  no 
guarantee  of  a  reaction  from  the  passive  partner.   (Something  as 
gross  as  a  temporary  line  disconnect  may  have  occurred. )   The 
remote  station  must  contain  a  timeout  mechanism  through  which  re- 
transmission of  the  same  record  (data  or  ACK/NAK)  can  be  effected. 

II.  DSO-Set  Data  Set  to  Output 

From  the  above  discussion  it  is  clear  that  after  receiving 
any  type  of  record,  we  are  either  going  to  again  search  for  SYNC 
characters  (in  case  of  undetermined  record  type  or  other  errors), 
or  are  going  to  condition  the  data  set  for  output  and  transmit 
either  an  ACK/NAK  or  a  data  record.   There  are  also  various  possible 
subsidiary  tasks  to  be  performed  (such  as  requesting  a  record  from 
the  6600,  setting  the  input  to  660O  flag  for  an  accepted  data 
record,  etc.)   One  subroutine,  DSO,  sets  the  data  set  to  output  and 
performs  all  of  these  additional  tasks.   DSO  is  directed  in  its 
decisions  by  the  status  of  the  input  and  output  device  buffers 
and  by  the  contents  of  CTL  —  the  first  control  character  to  be 
output.   These  indications  were  of  course  set  during  the  course 
of  input,  and  will  be  discussed  below. 

There  are  two  instances  where  an  immediate  reply  is  either 
not  possible  or  not  advisable.   We  cannot  very  well  transmit  a  new 
data  record  until  it  is  provided  by  the  660O,  and  we  should  not 
transmit  an  ACK  until  the  last  received  record  has  been  accepted 
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by  the  660O.   (This  last  consideration  is  to  avoid  signalling 
the  remote  station  to  transmit  a  new  record  while  we  have  no  place 
to  store  it. )   On  the  other  hand,  should  we  delay  transmission  we 
risk  triggering  the  remote  station's  timeout  mechanism.   The  solu- 
tion is  to  transmit  a  sequence  of  "IDLE"  characters  (8  bits  all 
ones)  until  conditions  warrant  transmission  of  the  desired  record. 
The  effect  of  the  IDLE  character  stream  on  the  remote  terminal  is 
to  keep  it  searching  Indefinitely  for  SYNC  characters,  and  these 
will  of  course  be  the  first  characters  of  the  ultimately  trans- 
mitted record.   There  are  two  TPV  settings  to  output  IDLEs: 
WTO  (wait  for  output)  and  WTO  (wait  for  clear  input);  and  DSO  sets 
TPV  in  accordance  with  the  character  it  finds  in  CTL  —  SOH  or  ACK 
(SOH  signifies  that  a  data  record  is  to  be  transmitted  and  requires 
a  WTO  setting,  whereas  ACK  requires  a  WTC  setting). 

With  the  additional  explanation  of  the  function  of  the  ALTx 
control  character,  we  will  be  in  a  position  to  complete  our  descrip- 
tion of  DSO.   This  control  character  must  immediately  succeed  the 
SOH  on  a  data  record,  and  it  has  two  valid  values.   The  value 
alternates  for  successive  records  and  affords  the  means  to  check 
for  redundant  retransmission  of  a  record  (the  ACK  may  have  been 
missed  by  the  transmitter).   There  are  three  possibilities: 

1.  ALT-expected  value       Data  record  is  to  be  forwarded 

to  6600  if  error-free,  and  ACK 
returned. 

2.  ALT-wrong  value  Data  record  is  to  be  discarded. 

If  error-free,  ACK  returned. 

3.  Non-ALT  ■   Search  for  SYNCs  (ignore  this 

record) . 
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The  decision  to  forward  or  discard  the  expected  data  Is 
immediately  recorded  within  the  status  word  of  the  input  device 
buffer  by  setting  or  clearing  the  reserve  flag.   Subsequently, 
before  storing  any  data  byte  into  the  buffer,  we  first  test  the 
status  and  if  clear  discard  the  byte.   If  any  error  is  detected 
before  the  entire  data  record  has  been  inputted,  we  ignore  the 
record  and  again  search  for  SYNCs.   When  the  entire  record  has 
been  read  in,  either  ACK  (error-free)  or  NAK  (error)  is  stored  in 
CTL  and  entry  made  to  DSO. 

Entry  to  DSO  is  also  accomplished  after  receiving  ACK  or 
NAK,  but  in  these  cases  SOH  has  been  stored  in  CTL.   In  general 
the  output  buffer  status  is  reserved  —  for  the  remote  station  may 
ask  for  retransmission  of  its  contents  and  we  wish  to  preclude 
the  possibility  of  it  being  prematurely  overlayed  by  a  new  record. 
Upon  reception  of  ACK,  however,  we  know  that  the  buffer  contents 
have  been  properly  received  and  we  clear  the  buffer  status.   By 
examining  CTL,  DSO  will  note  that  a  data  record  is  to  be  trans- 
mitted, and  if  the  output  buffer  is  clear  the  660O  must  provide 
the  next  record.   The  request  for  this  record  is  made  by  sending 
a  request  code  (to  be  described  below)  through  the  input  buffer. 
The  entire  DSO  procedure  is  depicted  in  the  flow-chart  (Figure  A-1' 

III .  Data  Formats 

As  mentioned  in  the  body  of  this  report,  our  system  supports 
two  distlnce  types  of  data  records  —  fixed  length  (unit  record) 
ASCII  and  variable  length  packed  (CDC)  internal  format.   The 
required  record  layouts  are  depicted  in  Figure  A-2.   The  SOH  and 


29 


ALT  are  common  to  both  types  and  have  been  described  above.   The 
next  control  character  indicates  the  mode  —  "binary"  (a  misnomer 
-  "packed"  is  more  accurate)  or  ASCII.   If  ASCII,  8o  8  bit  bytes 
(each  byte  of  odd  parity)  an  EOT  (end  of  text)  control  character 
and  a  longitudinal  record  check  (LRC)  follow.   The  characters  are 
translated  and  packed  two  to  a  word  into  the  input  buffer,  starting 
at  the  third  word  of  the  buffer,   (The  first  two  words  will  receive 
control  information  for  the  660O,  to  be  described  shortly. ) 

If,  however,  the  record  is  of  "binary"  type,  the  next  two 
input  bytes  each  contain  the  word  count  (number  of  12  bit  words) 
of  the  following  bit  stream.   This  bit  stream  is  (except  for  the 
first  24  bits)  entirely  unrestricted  and  will  be  passed  on  through 
XR.EM0TE  completely  untampered  with.   The  usual  type  of  data  is  a 
string  of  compressed  card  images  (trailing  blanks  deleted)  in  a 
6  bit  code,  but  binary  data  is  also  freqaently  transmitted. 
BINRT's  processing  of  this  bit  of  stream  is  to  pack  it  into  the 
proper  input  buffer  and  ascertain  its  validity  by  the  position  of 
the  EOT  and  even  longitudinal  parity  with  the  LRC.   (Since  all  bits 
of  each  byte  are  used  for  data,  there  can  be  no  parity  checks  on 
individual  inputs.) 

The  first  24  bits  of  each  record  passed  on  to  the  660O  con- 
tain control  Information.   At  present  the  controls  are  limited  to 
the  6  indicated  in  Figure  A-2,  and  they  communicate  file  genera- 
tion commands  to  XREM0TE.   The  "binary"  records  include  their  own 
controls,  and  BINRT  insets  the  01  for  ASCII  records.   End  file  and 
end  record  commands  for  ASCII  records  are  communicated  via  reserved 
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words  within  the  data  records.    The  "request  record"  (02)  may 
not  be  used  by  terminals,  but  is  the  vehicle  by  which  DSO  requests 
a  record  in  response  to  ACK. 

The  system  has  the  capability  to  output  in  the  same  2  formats 
as  it  inputs.   None  of  the  remote  terminals,  however,  have  yet 
developed  supporting  software  for  reception  of  binary  transmission 
and  all  output  is  currently  in  ASCII.   It  is  accomplished  by  trans- 
mitting a  few  sync's,  stepping  through  the  required  control 
characters,  and  then  unloading  the  buffer  and  translating  character 
by  character.   At  the  end  of  the  record,  the  required  EOT  and 
accumulated  longitudinal  record  check  (LRC)  are  appended. 

IV.  Terminal  Communication  with  BINRT 

The  overall  regulations  by  which  the  terminals  must  abide 
have  been  described  above  in  Section  I,  and  the  functions  of  the 
various  control  characters  have  also  been  discussed  in  that  and 
succeeding  sections.   The  control  character  values  are  listed  in 
Figure  A-J>.      We  will  discuss  here  some  additional  pertinent  informa- 
tion regarding  terminal  software  requirements.   Since  the  ASCII 
record  format  follows  the  Univac  DCT-2000  conventions,  the  inter- 
ested reader  is  referred  to  the  DCT-2000  Principles  of  Operation 
Manual  for  details  to  supplement  this  discussion  which  centers  upon 
the  binary  format. 

As  indicated  in  Figure  A-2,  the  unique  portion  of  the  binary 
record  is  framed  by  the  MODE  (which  identifies  the  record  as 
binary)  and  the  EOT.   The  twice  transmitted  word  count  refers  to 


EOF  or  EOR  in  columns  ] -3  with  the  remainder  of  the  record  blank. 
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the  number  of  12  bit  units  from  the  2^  bit  record  type  code  to  the 
end  of  data  inclusive.   The  acceptable  variations  of  the  size  of 
the  data  field  are  governed  by  the  660O  central  memory  (CM)  word 
length  of  60  bits,  for  the  data  is  to  be  stored  directly  and 
untampered  with  into  CM.   The  data  field  length  must  be  an  integral 
number  of  CM  words  and  the  maximum  data  field  size  is  50  CM  words 
or  3000  bits. 

The  EOT  must  be  aligned  at  an  8  bit  (character)  boundary, 
and  if  the  data  field  contains  an  odd  number  of  CM  words,  h   bits 
of  padding  must  be  appended  to  the  field.   Except  for  these  bits, 
according  to  the  strict  specifications  the  EOT  character  should 
immediately  follow  the  last  data  character.   However,  because  of 
implementation  difficulties  for  some  terminals,  we  tolerate  up  to 
24  additional  extraneous  bits  before  the  EOT.   All  of  this  padding 
is  completely  ignored  by  the  system  and  does  not  even  enter  into 
the  LRC  checksum. 

The  data  field  must  be  formatted  in  accordance  with  the  CDC 
internal  code  specifications.   The  data  may  be  either  a  binary  bit 
stream,  or  a  string  of  6  bit  CDC  "display  code   characters   con- 
forming with  the  CDC  blocking  convention.   This  convention  is  that 
each  logical  record  (usually  a  card  or  print  line  image)  is 
terminated  by  a  string  of  at  least  12  zero  bits  in  the  low  order 
position  of  a  CM  word,  and  that  trailing  blanks  may  be  omitted  from 
such  records.   (No  valid  display  code  character  translates  into  a 


See  Control  Data  6400/65OO/66OO  Computer  Systems,  Scope  Reference 
Manual  (Publication  No.  6OI8940O);  Appendix  A. 
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binary  zero,  and  the  terminal  zero  string  may  extend  for  a  full 
60  bits  if  necessary. ) 

As  explained  in  Section  I,  the  remote  terminal  must  contain 
a  timeout  mechanism  to  retransmit  the  last  message  if  it  receives 
no  response.   One  second  is  a  reasonable  timeout  delay.   If,  how- 
ever, anything  at  all  is  being  transmitted,  no  matter  how  long  or 
how  irrelevant,  the  timeout  mechanism  should  not  be  invoked. 
Otherwise  there  is  a  risk  of  losing  synchronization  of  the  conversa- 
tion.  (See  the  discussion  of  the  IDLE  transmission  in  Section  II.) 
The  ALTx  characters  should  be  dealt  with  in  precisely  the  same  way 
as  the  central  site  does  —  alternating  for  successive  messages  and 
not  alternating  for  retransmission. 

The  receiving  portion  of  the  terminal  software  parallels  the 
receiving  algorithm  of  the  central  site,  with  of  course  the  addition 
of  the  timeout  to  retransmit  ACK  or  NAK.   As  already  mentioned,  we 
have  the  capability  to  transmit  either  ASCII  or  binary  to  the 
remote  terminals. 
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APPENDIX  B  -  XREM0TE,  REMOTE  JOB  PROCESSOR 

XREM0TE  Is  the  660O  central  processor  program  which  controls 
the  remote  batch  l/O-   It  is  FORTRAN  coded,  interfaces  with  the 
SCOPE  operating  system  residing  continuously  at  one  of  the  7 
"control  points",  and  occupies  less  than  5K  of  memory  including 
buffer  space.   At  one  time  in  its  early  development,  XREM0TE 
utilized  standard  FORTRAN  READ  and  WRITE  statements,  but  this  soon 
proved  inadequate.   The  system  l/O  package  is  quite  large,  couldn't 
handle  our  blocked  record  types,  and  did  not  give  desired  control 
over  processor  usage.   All  that  we  really  need  are  subroutines  to 
load  (or  unload)  a  buffer  from  an  array,  manipulate  the  buffer 
pointers,  and  communicate  a  request  for  physical  l/O  to  the  system 
monitor.   This  last  function  is  accomplished  through  a  fixed 
"mailbox"  location,  and  the  entire  project  was  rather  straight- 
forward. 

What  XREM0TE  does  basically  is  to  read  DDP  input  buffers, 
write  their  contents  onto  individual  disk  files,  and  upon  sensing 
end  of  file  convert  the  already  generated  files  into  input  files 
for  the  job  queue.   On  output  there  is  an  initial  consideration  of 
identifying  and  locating  the  desired  file,  but  then  for  each 
"request  record"  received  from  the  DDP  the  individual  disk  file  is 
read  and  a  record  transmitted  to  the  DDP.   Record  counts  are  main- 
tained, and  at  the  end  of  each  Input  or  output  file  an  accounting 
record  is  entered  into  the  system  accounting  file.   PP  routines 
which  support  the  system  are  CIF  (create  input  file),  DOT  (search 
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for  "remote  output"  file),  and  RIO  (test  the  DDP  status  for  Input). 
RIO  merely  reads  the  status  register  and  tests  the  appropriate 
bit  to  determine  if  there  are  any  remote  input  records.   GIF  and 
DOT  will  be  described  at  appropriate  points  below. 

SCOPE  File  Structure 

All  l/O  requests  in  the  scope  system  must  specify  the  "name" 
of  the  file  to  be  accessed,  and  the  requests  are  processed  via  a 
File  Table  accessible  only  to  PP  programs.   This  table  contains  an 
entry  for  every  file  known  to  the  system,  including  input  jobs, 
output  (print)  files,  permanent  files,  and  local  files.   The  latter 
are  files  attached  to  a  running  job,  and  their  table  entry  is 
created  either  by   a   control  card  (requesting  assignment  of  a 
tape  or  other  external  equipment  such  as  the  DDP)  with  operator 
approval,  or  implicitly  upon  the  first  l/O  request  for  a  non- 
existent file.   In  the  latter  situation  the  file  is  assigned  to  the 
disk  with  nominal  storage  space,  and  additional  space  is  allocated 
as  needed. 

Implementation  of  our  remote  batch  system  entailed  adding  an 
additional  control  card  to  the  system—  REM0TE  (file  name,  XX ) , 
where  XX  is  a  2  digit  octal  Integer.   Any  job  (not  necessarily  one 
entered  via  a  remote  terminal)  may  use  this  control  card.   Its 
effect  is  to  modify  the  File  Table  entry  for  the  named  file, 
establishing  it  as  type  "remote"  and  recording  the  identifying  octal 
digits  within  the  entry.   Such  a  file  will  neither  be  printed  nor 
dropped  upon  job  termination,  but  will  remain  dormant  until  a 
remote  site  attempts  to  access  it  via  XREM0TE. 
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XREM0TE  uses  two  explicitly  assigned  files  to  communicate 
with  the  DDP  (herein  termed  INPUT  and  OUTPUT),  and  up  to  2n  (where 
n  is  the  maximum  number  of  data  sets)  dynamically  assigned  files 
—  an  input  and  an  output  file  for  each  data  set.   Buffer  space  is 
allocated  for  the  maximum  number  of  files,  but  a  buffer  is  not 
linked  to  a  File  Table  entry  unless  input  or  output  is  in  progress 
on  that  particular  line-   For  input  this  linkage  is  accomplished 
implicitly  upon  the  first  write  disk  request,  whereas  for  output 
a  call  to  DOT  locates  the  desired  file  and  links  the  File  Table 
entry  to  the  buffer. 

XREM0TE  Processing 

XREM0TE  periodically  attempts  to  read  those  DDP  device 
buffers  which  have  been  designated  as  data  set  input  buffers. 
(This  designation  is  encoded  within  the  INPUT  file  name  prior  to 
execution).   If  any  records  are  successfully  transferred  at  all, 
the  first  60  bit  word  of  each  record  contains  control  information 
(see  Figure  B-1),  and  there  may  or  may  not  be  additional  data 
following.   For  all  record  types  except  02  and  07,  any  additional 
data  is  written  to  the  disk  through  the  proper  input  buffer,  and 
if  applicable,  END  RECORD  or  END  FILE  indicators  are  produced. 
Upon  an  END  FILE,  XREM0TE  knows  that  it  has  completed  an  entire 
input  job  and  issues  a  call  to  OIF.    This  PP  routine  changes  the 


An  END  FILE  request  on  a  null  file  is  a  no-op.   It  is  proper 
operations  procedure  for  remote  stations  to  precede  all  input  with 
two  END  FILE  requests.   The  first  may  be  lost  if  the  ALT  is  not  in 
phase  (see  Appendix  A)  and  the  second  may  flush  out  possible  left- 
overs from  the  last  user.   Alternatively,  those  terminals  supporting 
binary  transmission  may  substitute  two  type  07  records. 
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File  Table  entry  for  the  file,  making  it  look  like  an  input  job 
and  detaching  it  from  XREM0TE.   This  is  all  that  is  needed  for 
the  file  to  enter  the  input  queue,  and  the  SCOPE  system  will 
henceforth  treat  it  in  precisely  the  same  fashion  as  any  locally 
entered  job.   XREM0TE  issues  the  necessary  accounting  records, 
and  —  since  the  input  buffer  is  now  attached  to  no  file  —  will 
process  further  inputs  through  the  same  buffer,  implicitly 
creating  a  File  Table  entry  on  the  first  write  request. 

When  a  job  executes,  "remote  output"  files  will  or  will  not 
be  created  depending  upon  the  inclusion  of  the  REM0TE  control 
card  in  the  input  deck.   If  this  option  was  indeed  exercised,  the 
File  Table  entry  will  have  received  the  above  mentioned  2  octal 
digit  identifier,  and  it  is  through  this  identifier  that  the  user 
requests  the  file. 

Each  time  XREM0TE  receives  an  02  record  type,  it  checks  to 
see  if  it  has  an  active  output  file  for  the  requesting  line.   If 
it  does,  it  retrieves  the  next  record  and  dispatches  it  through 
the  OUTPUT  buffer.   If  it  does  not,  it  checks  an  internal  table 
(JJOB)  for  an  indication  of  the  remote  output  file  identifier  to 
be  sought,   (The  identifier  is  entered  into  JJOB  when  the  first 
record  of  an  input  file  reads  ETX,  id#,  nn  where   nn  are  2  octal 
digits.   ETX  is  a  literal  string  otherwise  invalid  in  the  ID  posi- 
tion of  the  first  control  card  of  a  job. )   If  there  is  no  JJOB 
entry,  an  AWAITING  REQUEST  message  is  returned  through  the  OUTPUT 
buffer,  but  if  there  is  an  entry,  DOT  is  called  with  the  JJOB  entry 
and  a  buffer  address  as  arguments.   DOT  searches  the  system  File 
Table,  and  if  it  finds  a  file  with  a  matching  identifier  modifies 
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the  File  Table  entry  so  as  to  attach  the  file  to  the  designated 
XREM0TE  buffer,  whereupon  XREM0TE  commences  to  read  and  transmit 
records  In  response  to  successive  02  record  types.   If  DOT  Is 
unsuccessful  In  Its  search  It  indicates  the  situation  to  XREM0TE, 
which  In  turn  zeroes  out  the  JJOB  entry  and  returns  a  NO  OUTPUT 
message  through  the  OUTPUT  buffer.   Now  that  there  Is  no  longer 
a  JJOB  entry,  subsequent  02  record  types  (perhaps  generated  by 
automatic  ACKs  from  the  remote  terminal)  are  summarily  answered 
with  AWAITING  REQUEST  messages.   When  XREM0TE  senses  an  end  of 
file  on  an  output  file,  It  releases  the  file  and  its  disk  space 
to  the  SCOPE  system  and  issues  an  appropriate  accounting  record. 
The  next  "request  record"  will  generate  a  new  call  to  DOT  and  a 
search  for  another  file  with  the  same  Identifier,  with  the  same 
two  possible  results  as  above. 
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Is  accumulated  in  a  16  bit  field,  and  then 
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This  report  was  prepared  as  an  account  of 
Government  sponsored  work.   Neither  the 
United  States,  nor  the  Commission,  nor  any 
person  acting  on  behalf  of  the  Commission: 

A.  Makes  any  warranty  or  representation, 
express  or  implied,  with  respect  to  the 
accuracy,  completeness,  or  usefulness  of 
the  Information  contained  In  this  report, 
or  that  the  use  of  any  Information, 
apparatus,  method,  or  process  disclosed 
In  this  report  may  not  Infringe  privately 
owned  rights;  or 

B,  Assumes  any  liabilities  with  respect  to 
the  use  of,  or  for  damages  resulting  from 
the  use  of  any  information,  apparatus, 
method,  or  process  disclosed  in  this 
report. 

As  used  in  the  above,  "person  acting  on  behalf 
of  the  Commission"  Includes  any  employee  or 
contractor  of  the  Commission,  or  employee  of 
such  contractor,  to  the  extent  that  such  em- 
ployee or  contractor  of  the  Commission,  or 
employee  of  such  contractor  prepares,  dis- 
seminates, or  provides  access  to,  any  infor- 
mation pursuant  to  his  employment  or  contract 
with  the  Commission,  or  his  employment  with 
such  contractor. 
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